Как стать автором
Поиск
Написать публикацию
Обновить

Стартап за 100 дней. Неделя третья. Выделяем ключевые преимущества продукта. Используем LLM правильно

Уровень сложностиПростой
Время на прочтение7 мин
Количество просмотров1.3K

Привет, я Дима и хочу сделать стартап за 100 дней, а именно нескучное приложение для похудения. У меня за плечами опыт создания приложения с 20 МЛН установок и номинация «Приложение года» от Google. Смогу ли я повторить успех — покажет время, а пока буду делиться процессом создания, инструментами и подходами, которые сам использую.

Важно! Я не имею отношения к любым обозреваемым продуктам, которые использую в данной статье.

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

Ещё раз про онбординг пользователя

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

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

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

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

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

О чём буду говорить на онбординге

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

В моём случае, приложение для сброса веса, пользовательская инвестиция — это нечувствительные данные которые я могу собрать у человека:

  • Пол;

  • Возраст;

  • Рост;

  • Вес;

  • Физическая активность;

  • Пищевые привычки;

  • Имя (для персонализации обращения).

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

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

Первая мысль: в команду нужен эксперт по этой теме, кто-то из разряда дипломированного диетолога / нутрициолога, я хоть и немножко разбираюсь в этой теме — когда-то разработал программу и спроектировал онлайн сервис «Тренер» для одного известного сотового оператора, а для этого штудировал научную литературу, различные исследования и профессиональные публикации, чтобы разобраться как работает расщепление жира в организме, почему мороженое и арбуз хоть и имеют одинаковый гликемический индекс, но первое диабетикам нельзя, а второе умеренно можно (потому что гликемическая нагрузка разная и хотя скорость возникновения инсулинового притока будет высокая и там и там, но интенсивность будет в разы меньше)...

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

Ищем помощника для составления классного онбординга

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

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

Что в анализе самых дорогих стартапов последнего десятилетия, что в свежем отчёте Carta, говорится о том, что компании с тремя учредителями демонстрировали самый стремительный рост и только в стартапах «тяжелой индустрии», например, биотех — размер уcпешной команды должен быть больше: 3–5 основателей.

Средний размер команды у успешных технологических компаний — от 2,4 до 2,8 основателей, причем «классика» — это 2 учредителя (например, технический и коммерческий)
Средний размер команды у успешных технологических компаний — от 2,4 до 2,8 основателей, причем «классика» — это 2 учредителя (например, технический и коммерческий)

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

Результат оказался весьма успешный, при определённых НО:

Составление промпта: если в систему на вход подать ересь, то глупо ожидать на выходе мудрые мысли. Составление промпта, конечно, очень важная задача. Обычно, у меня есть разделение запросов к LLM: «по верхам» — когда нужно получить поверхностную информацию, быстро формирую запрос, почти как в Гугл и смотрю на результат, если не устроило, уточняю.

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

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

Проверка в нескольких сервисах: я использую сразу несколько сервисов, результат с одним и тем же запросом может быть очень разный в разных LLM. Моя конфигурация это: Perplexity, Gemini, ChatGPT.

Проверка конечного источника: обязательно нужно проверять те данные, что отдаёт LLM, много раз уже попадал на то, что либо исследования не с той области приплетены, либо информация устарела на сегодняшнюю дату или вот очень частый у меян кейс, когда идёт «перевирание» чисел, причём на порядки: «оборот этой компании составляет $500 000 в месяц», идёшь проверять, оказывается, $30 000 — $50 000 максимум, а это уже другой порядок выручки, другая «лига».

Или вот пример конкретно из запросов по исследованиям, которые мне нужны были для составления онбординга — запрос был про такую штуку, как «конический индекс» (используется для оценки распределения жира в организме, особенно в области туловища), вот такие ответы получил:

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

Perplexity:
«Конический индекс — это показатель, который характеризует сопротивление грунта проникновению конического индентора (пенетрометра) и определяется экспериментально с помощью стандартизированного прибора».

И только ChatGPT дал ответ соответствующий контексту антропометрического показателя.

Далее, я расширил промпт и получил куда более интересный результат:

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

И вот такая чехарда почти с каждым запросом: где-то лучше справится один, где-то другой.

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

В итоге, я остановился на том, что пока отдельный спец в команду не нужен, я сам недавно скидывал 20 килограмм и на себе понимаю боли и потребности аудитории. Плюс, есть комментарии пользователей под приложениями конкурентов ¯\_(ツ)_/¯ там обычно просто кладезь знаний про портрет и проблемы целевого потребителя.

Что добавляем на онбординг

От своей инвестиции в продукт пользователь должен получить пользу, поэтому помимо просчёта индекса массы тела, степени ожирения и нормы дневного калоража с дефицитом я добавлю ещё несколько элементов:

  • Показатель процента содержания жира в организме;

  • Общий показатель уровня жизни человека;

  • Тест на определение расстройства пищевого поведения.

Онбординг будет довольно внушительным, около 60 экранов. Сначала я подумал, что перебор, надо сокращать, потом пошёл пересмотрел записи онбордингов конкурентов и понял, что это вообще-то не так жу и много :) У одного из лидеров в индустрии вообще 80 экранов.

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

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

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

По итогу

Онбординг прошёл трансформацию — сначала «облако тэгов» и концепция блоков: что есть у других, что сделать у себя, что добавить такого, чего нет у других.

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

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

Далее была трансформация уже экранов в Фигме:

Эволюция: от черновых текстовых блоков, до кликабельного прототипа
Эволюция: от черновых текстовых блоков, до кликабельного прототипа

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

Вот предыдущая статья на тему основных блоков, которые должны быть на онбординге: Стартап за 100 дней. Неделя вторая. Проектируем онбординг приложения.

Теги:
Хабы:
-2
Комментарии6

Публикации

Ближайшие события