Жизнь AI стартапа после запуска
Как быстро развивать мобильное приложение и делать по два обновления в неделю? Как работа команды разработки вписывается в фин модель стартапа? На какие метрики может повлиять качество продукта? Пробую ответить на эти вопросы на реальном примере
Как команда разработки вписывается в финмодель стартапа
Время жизни любого стартапа определяется двумя числами - количеством имеющихся денежных средств (кэша) и скоростью их расходования (burn rate). Burn rate - это сколько денег стартап сжигает ежемесячно. Поделив количество кэша на burn rate можно получить количество месяцев, которое стартап сможет протянуть. Отсюда следует два вывода:
- Чем меньше burn rate, тем дольше стартап протянет на изначально выделенный под его тестирование кэш
- Чем раньше стартап начнет генерировать выручку, тем выше вероятность, что он протянет еще один месяц)
На начальном этапе развития стартапа лучше сфокусироваться в первую очередь на увеличении оборотки, а не на сокращении burn rate. На ранней стадии главная задача - как можно быстрее найти свою целевую аудиторию, завоевать рынок и нарастить продажи. Это позволит создать прочный фундамент для дальнейшего развития, а сокращение расходов может подождать. Да, контроль над burn rate важен, но на старте куда важнее инвестировать в то, что позволит вам увеличить доходы - будь то маркетинг, разработка, расширение команды и т.д.
В нашем случае мы определили с клиентом месячный бюджет разработки, в который включены нужные компетенции - мобильная и бэкенд разработка, дизайн, тестирование, продакт менеджмент и аналитика, промпт-инжениринг.
В зависимости от текущих задач мы больше вкладываемся в то или иное направление, оставаясь в рамках одного месячного бюджета. Это позволяет нам контролировать burn rate, предоставляя максимально широкий спектр компетенций при необходимости.
Типы обновления продукта
Чтобы быстрее вывести приложение в положительную экономику, наша команда разработки помогает улучшать обе части воронки - привлечение и удержание пользователей.
Привлечение пользователей
В эти обновления входят эксперименты с разными подписками, пробными периодами, ценообразованием для разных стран. Так же это работа с промо-материалами - Скриншотами приложения и демо-видео, тексты для страницы AppStore
Удержание пользователей
Тут мы пытаемся уже привлеченных пользователей удерживать в приложении максимально долго, давая качественное решение их проблемы, чтобы они продолжали платить за сервис. В первую очередь мы дорабатываем основной сценарий использования - суммаризация видео, повышаем качество и исправляем недочеты. Помимо этого пробуем разные дополнительные фичи - статистику суммаризаций, историю просмотров, разные настройки и тд
Планирование и частота обновлений
Чтобы за первые пол года приложение выросло в обороте в несколько раз, главное правило, которого мы стараемся придерживаться - сокращение time to market каждой конкретной фичи. Потому что пока фича не отправлена в AppStore мы не можем видеть как она влияет на метрики приложения, и получается это не приближает нас к улучшению экономики стартапа. Поэтому мы приняли у себя политику частых релизов. Максимальный промежуток между релизами - одна неделя. Чаще делать можно, но реже нет. У нас есть несколько правил, которые позволяют нам придерживаться такой политики:
- Выбирая между тем, чтобы отрелизить одно простое изменение или подождать еще несколько дней и собрать релиз побольше из нескольких фич - мы выберем отрелизить одно изменение, а новые фичи закончить параллельно и отправить их через пару дней
- Когда новая фича записывается в бэклог задается вопрос - “успеем ли мы закончить ее за одну неделю работы?”. Если ответ "нет", то нужно пять раз подумать каким образом ее стоит изменить или декомпозировать, чтобы можно было выпустить первую версию фичи в течении недели. Это не всегда реализуемо, но мы к этому стремимся
Что у нас сделано для достижения таких целей
- Отсутвие бэкенда на старте проекта. Это и экономит время на публикацию каждой фичи, и уменьшает расходы на команду разработки на 20-30%. Да, так можно. Да, это работает как полноценный продукт, который генерит выручку.
- Полностью автоматизированная система билдов, которая помогает экономить около 10-15% от времени мобильного разработчика и исключает простои из-за коммуникации. Любое изменение кода приложения, отправленное в git, автоматически создает новую версию приложения для теста и пингует QA. После успешного прохождения теста фича автоматически уходит в общее приложение, а набор фичей после регрессионного тестирования уходит в AppStore. И все это уже без участия мобильного разработчика, который в это время уже делает новые фичи
- Ведется и приоритезируется бэклог. Всегда есть набор небольших изменений, которые не требуют много времени, и больших фич, по которым нужно описание требований и дизайн. На планировании по бэклогу определяется как список небольших изменений, которые нужно взять в работу, так и проработка и внедрение больших фич
Какие минусы у данного подхода
- Сложно отследить как изменения влияют на метрики. Да, если делать хаотичные релизы с короткими промежутками, то сложно сказать что из них и как повлияло на метрики приложения.
- Потом периодически надо проводить работу по “вырезанию” фич из приложения. Тут уже включается анализ метрик и выбирается то, что пользователям не залетело, непонятно, что они не используют
В условиях маленькой и непонятной аудитории стартапа любое изменение будет иметь низкую точность, даже если провести кучу глубинных интервью и сделать много исследований. Поэтому по нашему мнению такой "картечный" подход будет наиболее эффективным. Он позволит вам быстро собрать разностороннюю обратную связь, понять, что действительно интересует ваших первых клиентов. А уже на основе этих данных вы сможете планировать более точные и результативные обновления в будущем.
Выводы (by AI)
- Приоритет на быстрые, частые релизы небольших изменений, а не на редкие, но масштабные обновления. Это позволяет быстрее собирать обратную связь и итерировать.
- Стараемся делать декомпозицию более крупных фич, чтобы они укладывались в недельный цикл. Это обеспечивает регулярность выпуска новых возможностей.
- Отсутствие бэкенда на старте и высокий уровень автоматизации процессов разработки и релизов. Это существенно ускоряет время вывода изменений.
- Признание того, что в условиях маленькой и непонятной аудитории стартапа любое изменение будет иметь низкую точность. Поэтому "картечный" подход с быстрыми итерациями оправдан.
- Понимание, что периодически придется проводить "вырезание" фич, которые не прижились у пользователей.
Такой подход мы используем при работе над проектами наших клиентов. Любые комментарии и обратная связь приветствуются, добро пожаловать в комментарии)
В следующей статье планируем рассказать про то, какие метрики мы собираем и как они помогают развивать этот продукт. Можете подписаться на мой блог на vc, если интересна эта тема и не хотите пропустить новую часть)
Запрыгнуть в AI-тренд с новым продуктом еще совсем не поздно. Половина людей ничего даже не слышали про LLM, ChatGPT и все что с этим связано. А среди тех кто слышал незначительно мало людей, кто самостоятельно генерирует юзкейсы, которые может закрывать AI, и подстраивает эту мощную технологию под себя. Поэтому большому количеству людей можно продать мечту о том, что магический Искуственный Интеллект решит одну из множества их проблем, достаточно лишь оплатить подписку)
Если вам интересно подробнее узнать про возможности создания AI приложений, то можете написать мне в телеграм @dmitrii_polushin