Привет, на связи Евгений, системный аналитик Purrweb — студии дизайна и разработки MVP для стартапов. В этой статье поговорим об ошибках, которые мешают стартапу покорить сердца юзеров и развиваться после релиза.
Ошибка 1. Не учитывать потребности целевой аудитории до запуска проекта
Иногда к нам в Purrweb приходят клиенты с идеями продуктов, которые мы называем «всё на черное». Владелец стартапа настолько уверен в своей гипотезе, что потребности и боли ЦА проверять не хочет. Такой проект может выстрелить, но чаще его сложно развивать и сделать коммерчески успешным. Он просто не нужен или не удобен пользователям.
Чтобы такого не случилось, рекомендую провести исследование аудитории до запуска проекта. Оно даст четкий срез потребностей будущих пользователей продукта, а иногда и неочевидные инсайты. Анализ бизнес-идеи и ЦА для стартапа стоит в агентствах около 300 000 ₽. При среднем чеке кастомной разработки в 7 млн ₽ посчитать потери в случае, если продукт не попадет в нужную аудиторию, несложно.
Продукт, который пытается охватить все ЦА сразу, можно сравнить с человеком-оркестром: насладиться конкретным инструментом сложно. А приложение для конкретной ЦА — как профессиональный дирижер, который создает идеально гармоничное звучание
Вот какие исследования будет полезно провести любому стартапу:
1. Количественное исследование: опрос. Задача этапа — получить статистические данные. Например, нужно сделать сервис для аренды жилья. В опросе мы узнаем, сколько времени в среднем уходит у собственника, чтобы сдать квартиру. Или как долго арендатору приходится искать жилье. Стоит оставить и поля для открытого ответа. В них респондент сможет написать свои мысли, а вы получите полезные инсайты.
Количество респондентов для опроса я советую определять с помощью онлайн-калькулятора. Он учитывает сразу несколько показателей, которые важны для расчета конечной выборки:
- Коэффициент уверенности (КУ) отражает, насколько мы будем уверены в результатах исследования. Я рекомендую выбирать стандартный КУ 95%, чтобы снизить вероятность провальных результатов до минимума — 5%. Такое соотношение оптимальное, когда нужен баланс между бюджетом, сроками исследований и их точностью.
Если брать КУ меньше, например 90%, мы пренебрегаем уверенностью в результатах, зато можем опросить меньше человек. Такой вариант подходит для продуктов с быстро развивающимся рынком или для сегмента B2B, где сложно собрать много респондентов.
- Погрешность исследования отражает, насколько полученные результаты отклоняются от истины. Например, мы опросили 100 арендаторов, 20% из которых ищут жилье больше полугода. Если мы задали погрешность в 10%, то допускаем, что количество таких арендаторов на реальном рынке может быть в диапазоне от 10% до 30%. Чем ниже показатель погрешности, тем более узким будет этот интервал и точнее результат.
- Общее число целевой аудитории отражает, сколько человек из нашей ЦА есть в России или другой стране. Здесь необязательно указывать точное количество. Например, мы опрашиваем тех же арендаторов. Понятно, что ЦА измеряется не десятками, не сотнями, а скорее миллионами человек, если речь идет о российском рынке. В этом случае можно задать 10 млн человек для расчета выборки. Если же вы делаете продукт для более узкой аудитории, ориентируйтесь на открытые статистические данные: Wordstat или Google Trends.
2. Качественное исследование: кастдевы. Это серия встреч с потенциальными пользователями. Так, в примере про сервис аренды жилья на кастдевах выясняют, какие проблемы есть у арендаторов и арендодателей, как выглядит график встреч с кандидатами, что бесит больше всего и удобно ли пользоваться продуктами, которые уже есть на рынке.
Мы опрашиваем около 20 человек, если сфера продукта понятна и хорошо изучена. Если же идея клиента лежит в менее очевидной плоскости — например, он хочет сделать приложение для сельскохозяйственных закупок, — выборку лучше увеличить до 40 респондентов.
О том, как провести кастдевы самому, рассказали в этой статье.
Форматы исследований мы подбираем, исходя из сложности продукта и объема рынка
По результатам исследований вы сможете точнее определить ЦА и сделать продукт под ее потребности. Если этим пренебречь, продукт будет очень сложно развивать, ведь он получится для всех и ни для кого конкретно.
Кейс из практики. Недавно к нам обратился стартапер, который хотел сделать соцсеть для желающих похудеть. Мы провели исследования и выяснили, что ЦА неинтересно постить фото себя в зале и общаться с единомышленниками. Зато было много респондентов, которые перепробовали все способы сбросить вес, но так и не достигли цели.
Мы предложили вместо соцсети сделать приложение, где юзеры смогут получить профессиональную помощь. Найти тренера или специалиста по питанию, который подберет личную программу похудения. В результате человек сможет достичь результата без жестких ограничений и стресса. Получится действительно полезный продукт, а не просто приложение в вакууме.
Ошибка 2. Включать в MVP много функций сразу
Представьте: стартапер решил создать маркетплейс товаров для фотографов. Механика приложения сложная: несколько магазинов, рекомендации, отзывы, платежный модуль, статусы доставки и даже нейросети под капотом. А стартапер решает делать всё сразу, хотя это дорого и долго.
Два года и десять миллионов рублей спустя предприниматель наконец выкатывает приложение на рынок. И вдруг оказывается, что половина фич вообще не нужна юзерам, а UI уже устарел и его надо изменить. Вместо того, чтобы развивать продукт, приходится топтаться на месте и переделывать то, что есть.
Мораль: для MVP лучше ограничить число функций. Например, для маркетплейса стоит начать с каталога, оплаты и доставки, а систему умных рекомендаций оставить на потом.
Вспомните, как зародился Телеграм: на старте это был простой мессенджер. Теперь это сложный продукт с чат-ботами, сторис, видеозвонками и рекламной платформой. Сперва Дуров протестировал, хороша ли его идея, а уже после этого стал развивать продукт и добавлять фичи. Это пример грамотного развития.
Чтобы определить главные функции приложения, советую использовать правило «большого пальца». На этапе кастдевов ищите главную боль аудитории и спрашивайте, насколько та или иная ситуация волнует человека по десятибалльной шкале. Если больше половины респондентов ставят уверенную десятку, значит проблема существует. Тогда приоритет мы отдаем той фиче, которая ее решит.
Кейс из практики
Мы в Purrweb разрабатывали сервис для удаленного ремонта квартир в Дубае. Клиент хотел сделать за три месяца мобильное приложение для пользователей, приложение для дизайнеров, админку для веба и лендинг, чтобы собирать заявки. За такой срок реализовать всё перечисленное нереально. Поэтому мы предложили версионный подход: начать с MVP-версии приложения, для нее выбрать самые приоритетные фичи, а потом постепенно наращивать функции. Всего запланировали пять версий приложения, чтобы после каждого этапа обновлять его в сторах. Так можно было бы постепенно увеличивать число функций продукта, а клиент мог бы влиять на его развитие, выбирая наиболее приоритетные фичи.
Все функции будущего приложения расставили по приоритету и разбили по версиям: для MVP оставили только ключевые.
Решили не усложнять дизайн и остановиться на минималистичном UI — чтобы не отвлекать юзеров от процесса ремонта.
Для следующих итераций задизайнили новые функции. Поделили ремонт на понятные этапы: что уже сделано, что в процессе и что предстоит сделать. А еще добавили портфолио дизайнеров, чаты и платежи.
Предложили добавить возможность отслеживать расходы на ремонт в приложении: пользователь может выбрать бюджет, посмотреть расходы, сохранить все чеки и счета в одном месте.
А чтобы юзеру было легче обозначить свои пожелания, мы придумали интегрировать бриф для дизайнера с тестовыми референсами.
Ошибка 3. Не учитывать в архитектуре, что продукт будет развиваться
Если мы заложили для приусадебного участка размер метр на метр, разбить там фруктовый сад технически невозможно. Так же и с ИТ-продуктом. На старте стоит предусмотреть в архитектуре резерв для его развития. Заложить условные 5–10 метров слева и справа от нашего метрового пятачка. Если этого не сделать, продукт не сможет расти и в скором времени перестанет закрывать потребности пользователей.
Например, стартапер планирует сделать соцсеть для меломанов. Идея выглядит так: музыкальный сервис и чат для общения. После релиза пользователи просят добавить систему рекомендаций и ленту новостей. Но продукт сделан на платформе no-code, поэтому добавить новые фичи сложно. Придется ограничиться чатом с проигрывателем или придумывать костыли.
В нашем примере стартаперу стоит применить первое правило масштабирования: спланировать наперед, как продукт будет развиваться, приоритизировать фичи и на старте обсудить это с подрядчиком. В этом случае всё можно предусмотреть заранее. И не придется переделывать всю функциональность приложения, чтобы добавить новую фичу.
Мы в Purrweb подходим к архитектуре комплексно, это помогает заложить резервы для будущего развития продукта
1. Выбираем способ построения архитектуры: монолит или микросервисы. Если у клиента нет много времени на разработку, но важна масштабируемость, мы рекомендуем делать монолит с модульной системой. Такую архитектуру можно в будущем разбить на микросервисы или добавить новые модули, а на старте разработчику не придется продумывать сложную архитектуру каждого микросервиса и систему взаимосвязей между ними.
2. Используем подход Domain-Driven-Design Эрика Эванса. Его еще называют предметно-ориентированным проектированием. DDD мы используем в случае монолитной архитектуры, так как с ним проще добавить в продукт новые фичи и, если нужно, поделить его на микросервисы.
Объясню, как это работает. В DDD-подходе существует понятие ограниченного контекста. Внутри одного такого контекста мы программируем решение задач по одной бизнес-цели. Допустим, в продукте уже есть два контекста: контекст планирования производства и контекст реализации плана на этом производстве. Если мы хотим добавить в продукт статус отгрузки товара, то внесем изменение в уже существующий контекст реализации. А если юзерам понадобится фича вне готовых контекстов, например управление филиалами производства, тогда лучше дополнить продукт новым контекстом.
Когда мы хотим добавить новую функциональность в продукт, отвечаем на вопрос: она относится к уже существующей бизнес-цели или к новой? Если цель новая, делаем новый контекст. Если она уже есть в системе, дополняем существующий. Такую систему несложно разделить на микросервисы, потому что все сущности уже расфасованы по контекстам, а коммуникация между ними понятна.
Решения по каждой бизнес-цели мы наносим на карту органических контекстов, а затем строим связи между получившимися сущностями
3. Выбираем подход к разработке: no-code или кастом. Первый вариант сразу накладывает ограничения на развитие: для приложения используют стандартизированное ПО. Time to market продукта будет намного короче, но потом его не получится масштабировать. С кастомной разработкой можно сделать приложение любой сложности и добавлять фичи до бесконечности.
Кастом всегда предполагает индивидуальный подход к идее клиента, поэтому стоимость разработки выше, чем у no-code-приложений
Ошибка 4. Не узнавать, ведется ли документация
Бывает так: стартапер заказал MVP у подрядчика, а развивать продукт решил с помощью инхаус-команды. Но вдруг он узнает, что никакой документации по проекту не велось. А значит, команде придется потратить месяцы, чтобы разобраться в чужом коде и вникнуть в бизнес-логику. Это время стартап буксует, а его владелец тратит деньги на зарплаты команды, которая не вносит ничего нового в продукт.
Мы не считаем, что на этапе MVP стоит упарываться в документацию и фиксировать каждый шаг, но есть несложные правила, которые облегчат жизнь в будущем. Рекомендуем проверить, выполняет ли команда разработки эти действия.
Ведет документацию бизнес-логики. Мы в Purrweb используем систему BPMN-диаграмм, которая иллюстрирует все этапы работы продукта. Например, клиент заказал пять творожных сырков в сервисе по доставке продуктов. Из BPMN-документации можно узнать, как именно сырки попадут к нему домой, а еще что будет, если на складе сырков не хватает или они закончились.
Так может выглядеть часть BPMN-диаграммы маркетплейса или интернет-магазина
Помимо BPMN-диаграмм мы в Purrweb ведем и другие документы. Например, UML-диаграммы и критерии приемки продукта. Но клиенту разбираться в них вовсе необязательно. Главное, что должно быть понятно из документации, — как приложение закрывает потребности целевой аудитории. Если из документации это не очевидно, стоит синхронизироваться с подрядчиком еще раз.
Что в итоге
Итак, чтобы не попасть в страшный сон стартапера, нужно:
- Выбрать конкретную целевую аудиторию и понять ее потребности и боли.
- Не делать из MVP сложный продукт с множеством функций.
- Убедиться, что команда разработки продумала архитектуру продукта так, чтобы его можно было развивать.
- Следить за документацией: она должна быть хотя бы в гигиеническом минимуме и содержать описание бизнес-логики продукта и критерии его приемки.
Готово, вы восхитительны! Шансы на успешный релиз и дальнейшее масштабирование повышаются. Если вам хочется больше узнать о секретах успеха развития ИТ-продуктов, приходите в наш телеграм-канал. Там мы много рассказываем о MVP и стартапах. До встречи в следующих статьях, stay tuned!
